Subject: Re: RTP Header Compression for Slow Speed Links

From: [email-masked] (RALPH K.B.CLAY)
Date: Mon, 3 Jun 1996 15:32:15 -0700

Hello Dave:  This is Ralph Clay --Yacl-- Somebody has included my 
address in their tech. info list.  just Junk what this is.  R.....

You wrote: 
>
>I think that you are sending this to the wrong email. I am David 
Boardman
>([email-masked]), but I don't understand what this email is 
about!
>
>
>Regards...  David BoardmanAt 03:57 PM 5/3/96 -0400, you wrote:
>>I am posting the following preliminary (and incomplete) Internet
>>Draft, so that we might get some comments and discussion going on
>>this list.  Scott and I submitted this just before the last IETF
>>in Los Angeles.  We plan to resubmit this with the details of the
>>compression technique we have in mind to the avt working group
>>mailing list, prior to the next IETF in June in Montreal.
>>
>>We are also in contact with the pppext working group, which will also
>>need to be involved in our approach to this problem.  Our intention
>>is to permit RTP to be used efficiently over dial-up modem lines
>>as the industry standard for encapsulating realtime voice over the
>>Internet, including in Internet Telephony applications.
>>
>>Please feel free to comment on this list, as it will assist us in
>>bringing forward a proposal which developers of Internet Telephony
>>software will want to support.  We will post the version with the
>>technical details of our proposal as soon as possible.  If you have
>>suggestions regarding which technical alternatives you would support,
>>now is the time to say so.
>>
>>We are looking at both VJ Compression and CCP as alternatives.  We 
expect
>>that the compression employed will be limited to the low speed link, 
in
>>order to facilitate multicast.  (By low speed, this could mean 
anything
>>from 14.4kbps up to 128kbps.)  We expect that compression will not be
>>end-to-end across the Internet.  This saves each end system from 
being
>>required to keep compression state associated with all other end 
systems
>>in the same multicast group, while retaining the compression on the 
link
>>where it is most valuable: the low speed dial up link.
>>
>> 
************************************************************************
*
>>
>> Internet Draft (Preliminary)                           Scott Petrack
>>                                                                  IBM
>>                                                        Ed Ellesson
>>                                                                  IBM
>>
>>                                                        February 1996
>>
>>
>>                 Framework for C/RTP: Compressed RTP Using
>>                 Adaptive Differential Header Compression
>>
>>         Abstract:
>>
>>         RTP (Realtime Transport Protocol) has been adopted as a
>>         Proposed Standard and is being widely implemented for
>>         the synchronized transmission of time-stamped data over
>>         IP networks, and has been shown to be effective at LAN
>>         speeds, T1 speeds, and Basic Rate ISDN speeds (128 kbps).
>>         However, a large number of users access the Internet at
>>         speeds of 14.4 and 28.8 kbps.  In order for such users
>>         to realize the maximum benefit of realtime audio and video
>>         applications, it is reasonable to apply whatever means
>>         possible to reduce header overhead.  A framework for
>>         header compression of RTP and for associated control
>>         protocols is herein proposed for use in these low
>>         bandwidth realtime scenarios.
>>
>>
>> Introduction:
>>
>> RTP (Realtime Transport Protocol) has been adopted as a Proposed
>> Standard, and is being widely implemented, for the synchronized
>> transmission of time-stamped data over IP networks, and has been 
shown to
>> be effective at LAN speeds, T1 speeds, and Basic Rate ISDN speeds 
(128
>> kbps).  However, a large number of users access the Internet at 
speeds of
>> 14.4 kbps and 28.8 kbps.  In order for such users to realize the 
maximum
>> benefit of realtime applications, it is reasonable to apply whatever
>> means possible to reduce header overhead.  By reducing header 
overhead,
>> the relative amount of bandwidth available for transmission of 
realtime
>> audio or video packets can be dramatically increased, while 
maintaining
>> acceptable packetization delay.  At these low speeds, a few kbps in
>> additional realtime packet throughput can make a dramatic difference 
in
>> user perception of quality in the received audio or video.
>>
>> This draft introduces the concepts which we have utilized to reduce
>> header overhead in realtime applications.  In order to negotiate or
>> pre-arrange header compression options, a session control protocol 
is
>> assumed.  The Session Description Protocol (SDP), defined by the 
mmusic
>> working group, could easily be modified to pre-arrange such 
compression
>> options for loosely controlled conference sessions.  For tightly
>> controlled sessions, the Simple Conference Invitation Protocol 
(SCIP)
>> also being defined by the mmusic working group, could be used to
>> negotiate or re-negotiate such options.  Alternatively, a modified 
H.245
>> protocol could also be used to negotiate header compression options 
as
>> part of the "capabilities exchange".  The specific modifications to 
these
>> protocols to control header compression options are beyond the scope 
of
>> this draft.
>>
>> RTP's overhead is approximately 12 bytes per packet, at minimum.  
The
>> impact of this RTP overhead, when used over low speed access lines, 
is
>> aggravated by the fact that in typical real-time audio applications, 
the
>> packet size is particularly small.  A telephony application using an
>> advanced codec might transmit 24 bytes every 30msecs.  Each packet 
is a
>> separate UDP write, which adds an additional 8 bytes.  Thus the 
total
>> overhead for both RTP and UDP is approximately 20 bytes for each 24 
byte
>> packet.  Over a 14.4 kbps connection, one has no choice but to group
>> packets together to reduce the bandwidth requirement, which 
increases
>> delay to an unacceptable degree for realtime interactive voice
>> conversations.  Even over a 28.8 kbps link, the overhead of RTP/UDP 
cuts
>> into the bandwidth available to audio and video applications.  This
>> translates directly into larger delays in the available service, 
because
>> the payloads must be grouped into larger packets to amortize the 
RTP/UDP
>> overhead.
>>
>> This draft documents two ideas that we have used to reduce the 
overhead
>> of RTP from 12 bytes to 2 bytes.  This reduction allows us to to
>> effectively eliminate the delay caused by RTP overhead on a low 
speed
>> link.  Although applying Van Jacobsen compression to the headers is
>> helpful, it is limited by the rapidly varying sequence number and
>> timestamp information.  The general compression scheme described 
here can
>> be summarized thus: the timestamp and sequence number fields taken
>> together include redundant time signal information.  They can be
>> compressed by standard adaptive differential methods.
>>
>> The extra compression is based on two ideas:
>>
>>     1. Use the time-related nature of the sequence and time stamp 
fields.
>>        In many cases, timestamps can be replaced by "timeclick 
numbers"
>>        which are one byte long, and these can be combined with the
>>        RTP sequence numbers. In general the timestamps and sequence
>>        numbers themselves form a simple time signal, and can be
>>        compressed without loss by standard adaptive differential
>>        methods.
>>
>>     2. Negotiate compression options before starting the RTP 
session.
>>        In many cases, certain RTP header fields do not change at all
>>        during the life of an RTP session.
>>
>> The two ideas presented here can be used independently.  For 
example, one
>> could send all the header fields in each packet, but still use the
>> special time-related nature of some of the fields to compress them.  
The
>> application that first interested us is transmitting audio and
>> audio/video over a PPP link.  In this case the two ideas together 
give a
>> much more efficient use of bandwidth.
>>
>>
>> Time-related compression:
>>
>> The basic idea here is that one cannot compress time-related data by 
the
>> usual VJ compression, because time related data is constantly 
changing.
>> But the changes in the time related data are often simple to model, 
and
>> an "adaptive differential" scheme can give good lossless 
compression.
>> For example, suppose there are no packet losses and the time stamp 
of
>> each packet increases by exactly one.  In this case, each timestamp 
is
>> different, so VJ compression will not compress, but in fact one can
>> dispense entirely with the timestamp field after the first.
>>
>> In general, there are two separate fields which relate to time:
>> the RTP sequence number, and the timestamp.
>>
>> In our internet telephone example, we have an application which 
sends one
>> UDP packet every 20msecs, except that during silence it sends 
nothing.
>> We always send the packets in order.  Instead of the timestamp and 
the
>> RTP sequence number, we send a single "timeclick number" with each
>> packet.  Each number represents 20 msecs, and from the timeclick 
number
>> we know exactly when it was sent (modulo 256*20msecs=5.12secs).  
Thus we
>> have a precise model for timestamps(i.e. timestamps always increase 
by
>> 20msecs), and this allows us to transmit the information in a single
>> byte.
>>
>>
>> Session control and compression:
>>
>> The second idea is an extension of well known VJ compression.  We 
have
>> found that in multimedia applications over low-speed links, every 
bit can
>> be very precious.  VJ compression is an in-band technique, and uses 
a few
>> bits to signal a header which doesn't change.  One can save several 
a few
>> hundred bits per second by signalling the static parts of the 
headers out
>> of band.  We now discuss this technique.
>>
>> RTP is designed to run over connectionless, unreliable protocols, 
but it
>> has inherent in it the idea of an RTP session.  We have found that 
it is
>> very natural to set up, control, and tear down an RTP session using 
a
>> separate session control protocol, which, in our implementation, 
uses a
>> reliable form of transmission.  The RTP bytestream itself still runs 
over
>> the unreliable protocol - only the non-real-time control is done via 
a
>> the session control protocol.  One of the important benefits of 
doing
>> this is that we can compress the unreliable RTP bitstream even 
further.
>>
>> Example:  Think of a simple audio/video transmission application
>> (multicast or unicast).  Before streaming begins, some negotiation 
or
>> advertisement takes place (coder type, block size, bandwidth, etc.). 
 In
>> this way, each side has a common understanding of the coming RTP
>> bytestream.  (In our current implementation, the receiver sends a 
"ready
>> to receive" to the sender, and then the sender can start streaming - 
an
>> RTP session has begun.)  The RTP bytestream itself is sent over 
UDP/IP to
>> facilitate real time transmission.  To change a parameter in a 
session,
>> the RTP session stops streaming, and only then some new negotiation 
takes
>> place or the session is torn down and a new one established.
>>
>> One can use this model to implement every commonly used "phone 
service",
>> including multiparty conferencing.  The simplifying assumption is 
that an
>> RTP parameter can be negotiated only while the RTP stream is not
>> streaming.  This negotiation can take place in a comparatively 
leisurely
>> non-real-time manner.
>>
>> From an end user perspective, pausing the realtime flow to 
renegotiate
>> the control state is not unfamiliar.  Note that this model is very
>> similar to that provided by an ordinary analog phone call.  You pick 
up
>> the receiver and do some reliable signalling to set up a connection.
>> Once connected, the real-time stream is highly unreliable (noise, 
echo,
>> etc.).  In order to change the control state of the connection, the
>> exchange of real-time data must be suspended or stopped (call must 
be put
>> "on hold" or disconnected).  In analog phone systems, the "on hold"
>> indication is often signalled via a timed "hook flash", or temporary
>> disconnect.  In this paused state the real-time bitstream can be
>> renegotiated (e.g., you can dial someone else, etc.).  We do not 
propose
>> this model for all RTP realtime flows, but only those that are 
associated
>> with applications which can dramatically benefit from header 
compression
>> signaling via a separate session control mechanism.
>>
>> Here is the precise definition of our session mechanism:
>>
>> 1.  The originator contacts the receiver via some negotiation or
>> advertisement protocol and informs or negotiates in non-real-time 
the
>> bytestream characteristics.  (In our implementation, this phase ends 
with
>> the sender sending a messaging expressing readiness to receive.)
>>
>> 2. At this point the sender can start sending to the receiver using 
RTP.
>>
>> 3.  At any point in the stream, the sender can stop sending and then 
send
>> a "pause announcement".  This pause announcement is sent via the 
session
>> control protocol.  (In our current implementation, the receiver
>> acknowledges this pause announcement.)  Similarly, the receiver can 
send
>> a "pause request" and then wait for the sender to stop sending.  (In 
our
>> current implementation, the sender complies with such a request by
>> stopping to send, and also acknowledges the request by sending a 
"pause
>> announcement" in the control protocol.)
>>
>> 4.  Once the realtime stream is paused, and the correct pause 
message has
>> been received on each side, then the control connection can be used 
to
>> renegotiate the bitstream (return to item 1, above), or to end the
>> session.
>>
>>
>> There are two important points about using the above scheme:
>>
>> - The RTP bytestream itself is sent by UDP/IP, a stateless protocol.
>> All the state information is negotiated in the session control 
protocol.
>> This is possible because there is a very simple synchronization 
between
>> the two channels, done in non-real time.  The statelessness of the 
RTP
>> stream makes it very simple to fulfill the realtime requirements.
>>
>> - The fact that all negotiation is done BEFORE the RTP stream 
begins,
>> allows the two sides to agree not to send RTP header information 
that is
>> going to remain static throughout the session.  Without this prior
>> negotiation, some bits would have to be used to flag these RTP 
header
>> fields.  By simply not transmitting these bits at all, one can 
squeeze
>> several hundred extra bits per second out of a low speed serial 
link.
>> This is often very precious when one is transmitting realtime audio 
or
>> video over a 14.4 kbps link.
>>
>> To summarize, although RTP allows the possibility to perform control 
of
>> the bitstream on the fly, in practice one can often agree in advance 
not
>> to do this, with no real loss in the useability of the available 
service,
>> depending on the application.
>>
>>
>> Multicast Considerations:
>>
>> The above discussion spoke about point-to-point unicast only for
>> simplicity.  It is easy to generalize to multicast environments, if 
a
>> advertisement or agreement protocol is used to synchronize the state 
of
>> the multiple endpoints.  The essential ideas (using a session 
protocol to
>> negotiate the stateless RTP stream, negotiating to omit uneccessary
>> fields, and performing an adaptive differential compression on the 
time
>> stamps and sequence numbers) apply equally in the multicast case.
>>
>>
>> Summary:
>>
>> We have found that much useful real-time conferencing can be done 
over
>> 14.4 and 28.8 kbps links.  But the difference between the 8+12 byte
>> overhead of RTP/UDP and 8+2 byte overhead of C/RTP can be the 
difference
>> between acceptable audio/video quality and intolerable audio/video
>> quality.  We definitely think that it is worth supporting 14.4kbps 
links
>> for real-time multimedia.
>>
>> References:
>>
>> 1. H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, "RTP: A
>>    Transport Protocol for Real-Time Applications", RFC1889,
>>
>> 2. H. Schulzrinne, "RTP Profile for Audio and Video Conferences with
>>    Minimal Control", RFC 1890,
>>
>> 3. M. Handley, V. Jacobson, "SDP: Session Description Protocol",
>>    Internet-Draft, Nov. 22, 1995.
>>
>> 4. H. Schulzrinne, "Simple Conference Invitation Protocol", 
Internet-
>>    Draft, February 22, 1996.
>>
>>
>> Author's Addresses:
>>
>> Scott Petrack
>> IBM Science and Technology Center
>> Haifa, Israel
>> Email: [email-masked]
>>
>> Ed Ellesson
>> IBM Networking Architecture
>> Research Triangle Park, NC, USA
>> Email: [email-masked]
>>**********************************************************************
*********
>>
>>Regards, Ed
>>
>>[email-masked]
>>legacy voice: 919-254-4115
>>
>>
>>
>**********************************
>David Boardman
>Technical Evangelist
>NSAPI, Java, JavaScript, VRML
>Netscape Communications Corp.
>[email-masked]
>
>